We are working on a integrated system with the DIY to support multi user OTrunk Reporting.

Originally we planned for a system where any ReportTemplate could be applied to any compatible AuthoredContent and group of users. However the OTrunk system isn't flexible enough for this approach yet. So instead we need to restrict the ReportTemplate to one AuthoredContent. See the "Possible Improvement" below so this restriction can be relaxed.

Current Design

ReportTemplate is bound to a particular AuthoredContent. The DIY needs to fill in the group of users. And the url to the AuthoredContent. The url to the AuthoredContent is filled in so the DIY can serve the AuthoredContent either directly from the source or from its cache.

Here is an example of the final result:

<?xml version="1.0" encoding="UTF-8"?>
<otrunk>
  <imports>
    <import class="org.concord.otrunk.OTSystem"/>
    <import class="org.concord.otrunk.OTInclude"/>
    <import class="org.concord.otrunk.view.OTViewBundle"/>
    <import class="org.concord.otrunk.view.OTViewEntry"/>
    <import class="org.concord.otrunk.view.OTMultiUserRoot"/>
    <import class="org.concord.otrunk.view.OTUserDatabaseRef"/>
    <import class="org.concord.otrunkcapa.OTCAPAReportTemplate"/>
  </imports>
  <idMap>
    <idMapping local_id="script_object" id="9ddf1254-a4da-11dc-96ee-0155390dc58c!/activity_script"/>
  </idMap>
  <objects>
    <OTSystem local_id="system">
      <bundles>
        <OTViewBundle>
          <views>
            <OTViewEntry objectClass="org.concord.otrunk.view.OTMultiUserRoot" viewClass="org.concord.otrunk.view.OTMultiUserRootView"/>
            <OTViewEntry objectClass="org.concord.otrunkcapa.OTCAPAReportTemplate" viewClass="org.concord.otrunkcapa.OTCAPAReportTemplateView"/>
          </views>
        </OTViewBundle>
      </bundles>
      <includes>
        <OTInclude href="capa_labview_activity.otml"/>
      </includes>
      <root>
        <OTMultiUserRoot local_id="multi_user_root">
          <userDatabases>
            <OTUserDatabaseRef url="file:///Users/skim/proj/loops/micah.otml"/>
            <OTUserDatabaseRef url="file:///Users/skim/proj/loops/james.otml"/>
            <OTUserDatabaseRef url="file:///Users/skim/proj/loops/nicholas.otml"/>
            <OTUserDatabaseRef url="file:///Users/skim/proj/loops/glen.otml"/>
          </userDatabases>
          <reportTemplate>
            <OTCAPAReportTemplate script="${script_object}"/>
          </reportTemplate>
        </OTMultiUserRoot>
      </root>
    </OTSystem>
  </objects>
</otrunk>

This would be generated from a "template" where the OTMultiUserRoot looks like this:

        <OTMultiUserRoot local_id="multi_user_root">
          <reportTemplate>
            <OTCAPAReportTemplate script="9ddf1254-a4da-11dc-96ee-0155390dc58c!/activity_script"/>
          </reportTemplate>
        </OTMultiUserRoot>

The code for modifying the otml file should look for the OTMultiUserRoot element with a local_id attribute of multi_user_root and add the userDatabases element from above:

          <userDatabases>
            <OTUserDatabaseRef url="file:///Users/skim/proj/loops/micah.otml"/>
            <OTUserDatabaseRef url="file:///Users/skim/proj/loops/james.otml"/>
            <OTUserDatabaseRef url="file:///Users/skim/proj/loops/nicholas.otml"/>
            <OTUserDatabaseRef url="file:///Users/skim/proj/loops/glen.otml"/>
          </userDatabases>

The template would have the following element in it:

        <OTInclude href="replace:authored_content"/>

It is quite likely that the report template will include other otml files. So the other <OTInclude> elements inside of <includes> should be preserved.

Possible Improvement

There is definitely a lot of places where this approach could be improved, but this seems the most practical for right now. There is one improvement that seems practical but since I'm not doing the work I don't know. If this improvement is not clear, or doesn't fit with how the DIY should be heading, then it isn't worth doing. It is more important to get something flexible, working quickly, even it is a little cumbersome.

The ReportTemplate otml will probably be used for several activities. The only change will be the references to the objects in the AuthoredContent. These changes can be encapsulated in the <idMap> element, like they are above. So parts of the idMap could be generated by the DIY this would eliminate the need for the mulitple copies. And we could get closer to our original design.

This could be done by adding a list of "bindings" to the relation between an DIY activity and ReportTemplate. These "bindings" would be of the form:

report_template_local_id, diy_activity_global_id

Both items are just strings.

These would be added to the <idMap> element using this form:

    <idMapping local_id="[report_template_local_id]" id="[diy_activity_global_id]"/>

It is possible that the report template will have other <idMapping> elements inside of the <idMap> these should be preserved.

These binds should be added to the "relation" between the DIY Activity and the ReportTemplate so that multiple report templates can be connected to a single DIY Activity. And each report template might require a different set of bindings.